Automated semantic tagging

ABSTRACT

Methods and systems are disclosed for automated semantic tagging that include detecting a particular thread executed by a processor and identifying a root process of the particular thread. An object-process link may be by linking an object that executed code that called the particular thread to the root process. A thread list of thread definitions of the object may be identified. A particular thread definition that corresponds to the particular thread can be mapped. Resource types to be consumed upon executing an instance of the thread instantiated from the particular thread definition can be identified and the corresponding values of the resource types can be determined. A process specification can be generated that encapsulates the thread definition, resource types and values so as to reproduce a state of the root process at a point in which the particular thread executed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/560,782, filed Sep. 4, 2019, the entire disclosure of which isincorporated by reference, for all purposes, as if fully set forthherein.

FIELD

The present invention relates generally to the automated semantictagging, and more particularly to a transaction framework incorporatingsemantic data.

BACKGROUND

Software executing within a hardware environment is often composed of anumber processes that can execute to provide the functionality of thesoftware. Each process may be composed of discrete sets of instructionsthat execute to provide intermediate functionality of the process. Sinceeach set of instructions is discrete, the processor of the hardwareenvironment executes each set without regard to the set of instructionsthat came before a particular set or the set of instructions that willexecute after. This may compound problems caused by poorly developedsoftware, software errors, and memory leaks. For instance, lackingdetails of other sets of instructions may cause the processer to executeduplicate sets of instructions or to execute an infinite loops, whichmay occur when a set of instructions points to a previously executed setof instructions as the next set of instructions to be executed.

In some instances, the hardware environment may address the issue byusing a scheduler to schedule each set discrete for execution by theprocesser of the hardware environment. The scheduler may receive someinformation associated with sets of instructions to be executed andprovide further analysis in attempt to progressively schedule each set.Yet, while the scheduler has more detail with respect to the number ofsets to be executed, an intended order, etc., the scheduler often lacksthe information to able to prevent duplicates or infinite loops. Forinstance, schedulers lack state information associated with the sets ofinstructions such as input/output, memory registers, associations withother sets of instruction or processes, branches, etc.

SUMMARY

Aspects of the present disclosure include methods for automated semantictagging by generating process specifications for threads. The methodsinclude detecting, by a semantic mapping application programminginterface (API), a particular thread executed by a processor;identifying a root process of the particular thread, the root processproviding a function to a computing device by executing one or morethreads, the particular thread being one of the one or more threads, andwherein and the particular thread providing an intermediate function ofthe process; generating, based on the particular thread and the rootprocess, an object-process link by linking an object that executed codethat called the particular thread to the root process; identifying athread list of the object that includes an identification of one or morethread definitions, wherein each thread definition is configured toinstantiate a thread; generating process specification for the rootprocess by: matching a particular thread definition of the one or morethread definitions to the particular thread; identifying, using theparticular thread definition, an identification of one or more resourcetypes to be consumed upon executing an instance of the threadinstantiated from the particular thread definition; determining a valuecorresponding to each resource type of the one or more resource types;and generating a process specification that encapsulates the threaddefinition, identification of the one or more resource types, and thevalue corresponding to each resource type of the one or more resourcetypes, the process specification configured to reproduce a state of theroot process at a point in which the particular thread executed.

Another aspect of the present disclosure includes a system comprisingone or more processors and a non-transitory computer-readable media thatincludes instructions that when executed by the one or more processors,cause the one or more processors to perform methods described above.

Another aspects of the present disclosure include a non-transitorycomputer-readable media that includes instructions that when executed byone or more processors, cause the one or more processors to perform themethods described above.

Further areas of applicability of the present disclosure will becomeapparent from the detailed description provided hereinafter. It shouldbe understood that the detailed description and specific examples, whileindicating various embodiments, are intended for purposes ofillustration only and are not intended to necessarily limit the scope ofthe disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is described in conjunction with the appendedfigures:

FIG. 1 illustrates a block diagram of a semantic tagging system 100according to at least one aspect of the disclosure.

FIG. 2 is a block diagram of a semantic tagging system frameworkaccording to at least one aspect of the disclosure.

FIG. 3 is a block diagram of the semantic tagging system according to atleast one aspect of the disclosure.

FIG. 4 illustrates a block diagram of various processing views of avariant case during operation of semantic tagging according to at leastone aspect of the disclosure.

FIG. 5 is a block diagram of various processing views of a divergentcase during operation of semantic tagging according to at least oneaspect of the disclosure.

FIG. 6 is a flowchart of a process for generating process specificationsaccording to at least one aspect of the disclosure.

In the appended figures, similar components and/or features may have thesame reference label. Further, various components of the same type maybe distinguished by following the reference label by a dash and a secondlabel that distinguishes among the similar components. If only the firstreference label is used in the specification, the description isapplicable to any one of the similar components having the same firstreference label irrespective of the second reference label.

DETAILED DESCRIPTION

The ensuing description provides preferred exemplary embodiment(s) only,and is not intended to limit the scope, applicability or configurationof the disclosure. Rather, the ensuing description of the preferredexemplary embodiment(s) will provide those skilled in the art with anenabling description for implementing a preferred exemplary embodiment.It is understood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope asset forth in the appended claims.

The automated semantic tagging system monitors execution of threadswithin a processing environment and tags additional data to the recordof the execution to generate process specifications that can recreatethe state of a process at a point in which the thread of the processexecuted. A configuration layer enables configuration of objects,threads, and processes that can be monitored during execution of theapplication. An interface between an application class and theconfiguration layer may enable detection of the objects, threads, orprocesses during execution. Upon detecting execution of a monitoredthread, for instance, triggers generation of a process specificationthat encapsulates the relationships between the thread, the object thatcalled the thread, the process within which thread is executing, and athread definition of the thread that indicates the design timeproperties of the thread. THe process specification may be storedlocally or remotely and used to refine the application during or afterruntime.

Each process may be represented by multiple process specifications withone process specification corresponding to each thread of the process.This can allow for tracing the state of the process through the entireexecution of the process. In some instances, the process may be replayedin a simulation that reproduce the exact functionally of the particularprocess when it executed including any particularities of thatparticular execution such as errors, faults, resource leaks, cycles, orthe like. The computing device may step through each thread of theprocess to identify root cause of the error, fault, resource leak,cycles, or the like (e.g., the particular thread, the particularexecution conditions, particular instructions, or the like).

In some instances, the process specification may be used to modify theprocesses of the application either during runtime as the processes areexecuting or before a subsequent execution. For instance, the root causeof particular functionality (e.g., errors, execution time, resource use,or the like) may be used to modify threads of a process prior to thethreads subsequent execution in order to reduce or eliminate thefunctionality. The thread definitions may be modified by adding resourceconstraints to the allocation of resources, modifying loops, modifyingconditional branches, adding exception handling, modifying networktargets to redirect requests of the threads to different computingdevices, or the like.

These illustrative examples are given to introduce the reader to thegeneral subject matter discussed here and are not intended to limit thescope of the disclosed concepts. The following sections describe variousadditional features and examples with reference to the drawings in whichlike numerals indicate like elements, and directional descriptions areused to describe the illustrative aspects but, like the illustrativeaspects, should not be used to limit the present disclosure.

FIG. 1 illustrates a block diagram of a semantic tagging system 100according to at least one aspect of the disclosure. Semantic taggingsystem 100 may execute one or more processes of one or more softwareapplications. In some instances, the at least one software applicationof the one or more software applications may be a distributed softwareapplication that executes on one or more computing devices or threadexecution cores. A software application may include one or moreprocesses (e.g., components) that provide the functionality of theapplication. The one or more processes may execute in series (e.g., oneprocess at a time), concurrently (e.g., such as one process executing inparallel with another process), or a combination thereof. When executingin parallel the processes may execute synchronously or asynchronously.

A process may include one or more threads (e.g., a set of instructionsthat provide a function such as a transaction) that execute to providean intermediate function of the process. Each thread can be executedindependently from other set threads. Like processes, threads can bescheduled to execute in series, concurrently, or a combination thereof.Some threads may be called by an object of the application layer. Forinstance, objects can include one or more thread definitions (e.g.,activities), each thread definition can be processed to generate aninstance of a thread. The thread definition may include, for example,one or more instructions executed by the thread, identification of oneor more other threads, resource types necessary to execute the thread, aroot process within which the thread can execute, combinations thereof,and the like. In some instances, processing the thread definition togenerate an instance of the thread can include compiling or interpretingthe set of instructions of the thread.

A process can be executed by one or more processors on one computingdevice or across multiple computing device (e.g., in a distributedprocessing system). For instance, computing device 104 may execute oneor more applications. Executing each application may include generatingone or more processes, which may include generating one or more threads.Applications 124 may be stored in persistent memory in a compiled oruncompiled state. When executed, the one or more sets of instructionsmay execute by processor 108 to spawn a process. As the processexecutes, instructions may execute to generate one or more threads thatcan be executed by processor 108 to provide the function of the process.Memory 116 may also include instructions 120 that can includeinstructions that are independent from applications 124 such as anoperating system or firmware, or the like or instructions thatfacilitate execution of at least one application such as hardwaredrivers, interfaces, previously executed processes, threads, or objects,or the like.

In some instances, an application may use a process specification ofprocess specifications 128 to modify a process of an application priorto spawning the process. For instance, computing device 104 may identifyan error such as an missed branch or an infinite loop that may waste theresources of computing device 104 and semantic tagging system 100. Aprocess specification may indicate the state of a thread of a process.Since threads are typically stateless, a particular thread may notindicate the cause of the error. A thread specification may provide thestate of the process at the point in which the thread executed toprovide an indication as to the cause of the error or wasted resource.Instructions 120 may include one or more routines for analyzing processspecifications such as by tracing the threads that come before or afterthe particular thread of the thread specification. The one or moreroutines may additionally, and automatically, execute to modify theprocess to eliminate redundant threads; eliminate cycles such asinfinite loops; reduce resource consumption such as processor cycles;memory use; network bandwidth; or the like.

Process specifications 128 may include process specifications that weregenerated from threads of processes previously executed by processor108. In some instances, process specifications 128 may includeadditional process specifications received over network 148 from othercomputing devices 152. Computing devices 152 may have a same, similar,or different structure from computing device 104. In some instances,process specifications may be analyzed using one or moremachine-learning models 132. For instance, one or more threadspecifications may be packaged into a feature set that can be input intoa machine-learning model to derive characteristics of process that maybe less prone to errors or a characteristic of processes that mayexecute with less resources of computing device 104 or semantic taggingsystem 100.

A feature set may be defined using sets of process specifications over atime interval. In some instances, a feature set may include each processspecification of a particular process. In other instances, a feature setmay include may include process specifications generated over a timeinterval such as process specification generated from multiple threadsacross one or more processes. This may be advantageous to capture errorsin a process that may execute correctly once despite previous executionsending in error. In some instances, features sets may be defined overvariable time intervals such as a first feature set that may include oneor more process specifications over a first time interval and a secondfeature set that may include process specifications over a second timeintervals. Features sets may be defined from process previously executedby computing device 104, from process executed by other computingdevices 152, or from a combination thereof. In some instances, featuresets may be generated from manufactured process specifications.Manufactured process specifications may be procedurally generated toinclude particular data, random data, or combination thereof.Manufactured process specifications may be generated by automatically orby an operator rather than from a process that executed by processor108.

The machine-learning models may be trained using feature sets fromprocess specifications 128, manufactured thread specifications, processspecification received from computing device 152, or the like.Machine-learning models 132 may be trained using supervised orunsupervised learning. In supervised learning, the feature sets caninclude labeled data that indicates an expected output such as an idealprocess, an ideal thread of a process, a state of a thread, propertiesof the process or thread, an error or fault, resources consumed by theprocess or thread, or the like. For example, the feature set may belabeled with a particular error. The machine-learning model may use thefeature set, as input, and the labels, as expected output, to define oneor more functions that will output identify a process or thread that maycause a similar error. The accuracy of the one or more functions, andthe machine-learning model, may depend on the number of feature setsused to train the machine-learning model. Examples of algorithms thatcan be used for supervised learning include, but is not limited to,regression such as random forest, linear and non-linear; Bayesianstatistics; neural networks; decision trees; Gaussian processregression; nearest neighbor; long short-term memory; deep learningalgorithms; combinations thereof; and the like.

In unsupervised learning, the feature sets may not be labeled such thatthe machine-learning model may not have access to the expected values ofthe one or more additional properties associated with a given inputfeature set. Since the expected values are unknown, the machine-learningmodel may use different algorithms from those used during supervisedlearning. Unsupervised learning may focus on identifying correlationsbetween (1) two or more thread specifications of a feature set, (2) twoor more processes of a feature set, (3) two or more threads of a featureset, or (4) two or more feature sets. The machine-learning model mayindicate that certain properties of a process specification are a betterindicator of predicting an error or identifying a root cause of an errorthan other properties. For instance, the machine-learning model mayidentify a correlation between a particular threads of a process and anerror detected upon executing the process that may indicate the order ofthe particular threads may be the cause of the error. In some instances,correlated properties may be weighted higher than other properties tofurther improve the identification of particular characteristics ofthread specifications. Examples of unsupervised learning algorithms formachine-learning models include, but are not limited to, clustering,neural networks, outlier detection, combinations thereof, or the like.

The machine-learning models may be trained over a predetermined intervalof time that can be based on the size of the feature sets (e.g., thequantity of process specifications in each feature set) and the numberof feature sets used for training. In some instances, training maycontinue until a predetermined threshold is met. For instance, trainingmay continue until a predetermine number of feature sets are processedby the machine-learning model 132. In another example, training maycontinue until the machine-learning model 132 reaches a predeterminedaccuracy threshold. Accuracy may be determined by passing labeledfeature sets into the machine-learning model and matching the output tothe label. In other instances, accuracy may be determined based on useranalysis of the training process, the output of the machine-learningmodels on contemporaneously collected process specifications, or therate at which the machine-learning model generates an output from agiven input. In some instances, the machine-learning models may becontinuously trained, first using the training feature sets and thenusing contemporaneously obtained process specifications from processspecifications 128 to further improve the accuracy of machine-learningmodels 132.

An accuracy value associated with machine-learning models 132 may beused to trigger re-training or provisioning new machine-learning models.If the accuracy value falls below a first threshold value then there-training or provisioning may be triggered. In the instance ofre-training, machine-learning models 132 may continue to analyze processspecifications, but the output may include an indication thatre-training has occurred to warn an operator that the output may not beup to the threshold level of accuracy. In the instance of provisioning,the machine-learning model may be replaced with a new machine-learningmodel. The new machine-learning model may be trained in the same manneras described above. In some instances, the output of machine-learningmodels 132 may be compared to a second and lower accuracy threshold,such that if accuracy falls below the first threshold but is above thesecond threshold, retraining may occur. If the accuracy falls below boththe first threshold and the second threshold, then a newmachine-learning model may be provisioned. The new machine-learningmodel may be trained in the same manner as described above.

Computing device 104 may include one or more input/output devices 140such as a keyboard, mouse, other human-machine interface devices, or thelike accept input from one or more users of computing device 104.Computing device 104 may include one or more display devices 136 thatcan provide a graphical user interface for the one or more users tointeract with applications 124, to provide or review analysis of processspecifications, modification of processes and threads, or the like.

Computing device 104 may include network interface 144 that provideswired and/or wireless communications with other devices of network 148.The network interface may enable computing device 104 and computingdevices 152 to operate a distributed environment for one or moreapplications of applications 124. For instance, an application ofapplications 124 may be a distributed application that executes oncomputing device 104 and on computing devices 152. Client devices 156may transmit commands to the application via computing device 104 orcomputing devices 152 through network 148 to coordinate the operation ofthe application. In this instance, computing device 104 and computingdevices 152 may provide all of the resources needed to execute theapplication and client device 156 may enable a remote user to access theapplication as if the application was executing locally. This may enablefaster execution of the application as the application can pool theresources of each device of the distributed environment. In addition,the user of client device 156 does not need to install the applicationlocally to access the full functionality of the application.

Servers 160 may store one or more applications that can be provisionedonto the computing device 104 and computing devices 152. For instance,client devices 156 may request access to a distrusted application thatis not currently running. Servers 160 may provision one or morecomputing devices, or as many computing devices as needed to provide thefunctionality or efficiency requested by the client devices 156, to byremotely installing the application onto the one or more computingdevices and establishing the distributed environment. Servers 160 maystore historical process specifications, error logs, event logs, and thelike.

Servers 160 may store the historical process specifications, error logs,event logs, and the like remotely in one or more databases such asthreads database 168 and process specifications database 164. Threadsdatabase 168, may store threads that have previously executed as well asthread definitions. Process specification database 164 may store theprocess specifications from previous executions of applications. In someinstances, computing device 104 may store thread definitions and processspecifications within threads database 168 and process specificationsdatabase 164 for later access. Central storage may enable processspecifications generated by computing device 104 to be accessed by othercomputing devices 152 executing the same distributed application. Thiscan further improve analysis of thread specifications across the entiredistrusted environment rather than at a single computing device.

FIG. 2 is a block diagram of a semantic tagging system frameworkaccording to at least one aspect of the disclosure. In some instances,the semantic tagging system framework includes a processing layer thatis between the application processes and system processes to enablecapturing state information of the application processes during andafter execution by the processor. The added processing layer enablescapturing process specifications for any application executing by acomputing device and the granularity detail captured to generate theprocess specification may be configurable by a user operating userinterface 204. In other instances, the application may be modified toinclude the added processing layer.

During configuration time, user interface 204 may enable user input tomodify a the processing layer or a build of the application. One or morehooks may be added to the processing layer or build to trigger dataacquisition upon detecting particular events such as thread execution.Prebuild 208 may include a portion of the processing layer orapplication that is preconfigured (e.g., without the hooks). Userinterface 204 may enable a user to add the configuration to the buildand execute a SavePostChange 212 command to post the change to the buildand save it. In some instances, SavePostChange 212 may require thesoftware build to be recompiled prior to execution. In other instances,the added content may be store separately from the build and compiled orinterpreted at runtime (e.g., using a just-in-time compiler or thelike).

The modifications added by user input may be used to configure asemantic mapping application programming interface (API) 216 provides aninterface between the component processing of the application and theprocessing layer that is specific to the application class. Semanticmapping API 216 includes one or more functions that enable access to theapplication class of the application. The application class of theapplication includes the objects, thread definitions, attributes, of theapplication. The semantic mapping API enables access to the data of theapplication class during runtime such that threads of a process of theapplication that are executed by the processor can be monitored. Forinstance, the semantic mapping API 216 may monitor an application andtrigger a flag, registry entry,

Once semantic mapping API 216 is configured to monitor particularaspects of the applications, the application may be executed. Duringexecution, the semantic tagging 220 may use the semantic mapping API 216to access the details of the application class. For instance, thesemantic mapping API 216 may trigger a flag when a particular threadexecutes. Semantic tagging 220 may access semantic mapping API inresponse to detecting the flag to gather details about the state of thethread. Semantic tagging 220 may generate a thread log 224 indicatingthat the thread executed including the thread definition for the thread.In addition, semantic tagging may generated a process specification log228.

For example, in response to detecting the flag, the semantic tagging 220may use the semantic mapping API 216 to identify a process (e.g.,component) of the application within which the particular thread (e.g.,transaction) executed and map the process to an object that called theparticular thread. The semantic tagging may further identify one or morethread definitions of the object, identify the particular threaddefinition that corresponds to the particular thread, identify theresource types (e.g., attributes) that correspond to the particularthread definition, and identify the value that correspond to eachresource type. The data may be packaged into the process specificationlog 228.

FIG. 3 is a block diagram of the semantic tagging system 300 accordingto at least one aspect of the disclosure. Automated semantic taggingsystem 300 provides for logging process specifications that can be usedto modify future processes at runtime. Configuration layer 304 mayinclude an interface to receive input that configures the processes,threads, and resources that can be monitored during execution of one ormore applications. For instance, mapping block 308 may provide a mappingbetween two properties of the automated semantic tagging system 300,such as object identifiers and process identifiers. Configuration layer304 may include mapping block 312, which provides a mapping betweenobject identifiers and thread definition identifiers, and mapping block316, which may provide a mapping between thread definition identifiersand attributes of a thread.

In some instances, the mapping of each property of mapping blocks 308,312, and 316 may include may include wildcard operators, timestamps,types, or the like to indirectly map the object identifiers and processidentifiers. For instance, mapping block 308 may indicate objects of aparticular type may be associated with processes of a particular type.Automated semantic tagging system 300 may not store static associationsthat may be known prior to runtime. Instead, configuration layer 304 mayprovide abstract mappings that in which the mappings may be detected atruntime. Configuration layer may include more or less mapping blocksthan mapping blocks 308, 312, and 316. In some instance, a mapping blockmay map more than two properties such as, by example, object, process,and thread definition. Mapping blocks may maps one-to-one, one-to-many,or many-to-many.

Configuration layer 304 may include a semantic mapping API that mayinclude logic to inspect application class processes 320. Applicationclass processing 320 may expose an interface that provides access toparticular types of processes, threads, variables, resources and thelike of an application to configuration layer 304. In some instances,each application may include its own instance of application classprocessing 320. In other instances, one instance of application classprocess 320 may operate for one or more applications. Application classprocessing 320 may expose all processes, threads, variables, resourcesand the like of an application or only portion thereof. For instance,for an application that provides varied functionality such as signalprocessing and data modeling, application class processing 320 mayexpose the processes, threads, variables, resources and the like thatcorrespond to the signal processing but not the data modeling.Application class processing 320 may mark some processes, threads,variables, resources and the like as exposed or protected throughmetadata or through code of the underlying application.

Application layer inputs 324 may be an interface between a input/outputdevices and the application executing on a computing device. Forinstance, the application layer inputs 324 may direct application layer328 to generate a process or execute one or more threads or modify oneor more processes or threads. Application layer inputs 324 may modifythe application layer data by tagging semantic processing data viasemantic mapping layer 332 to generate process specifications uponexecution of a particular thread.

Application layer 328 may represent the high level operations of anapplication executing on the computing devices. Application layer 328may include compiled instructions that generate processes that providethe functionality of the application, objects, object definitions, data,and metadata. Object definitions provides a flexible architecture forestablishing and maintaining relationships between various kinds ofthread definitions for each of the processes and forms the foundationfor the data layer model. Application layer 328 may instantiate objectdefinitions thereby generating an object of the application. Objects canbe a logical entity around which a specific threads may execute. Objectsmay include multiple thread definitions from which the object may callto execute a thread to provide intermediate functionality of a process.Objects may establish links to processes along with process specifickeys.

Application layer 328 generates processes and threads for execution byprocessors 376. During or after prosecution of each thread the state thethread may be captured as a process specification indicating the stateof the process at the point in which the thread executed. Execution ofthread 356 by processor 376 may trigger application class processing 320to execute process 336 to identifying the process 344 that correspondsto thread 356 and map process 344 to the object identifier of object 340that called the thread. Once mapped, application class processing 320may execute process 348 to identify each thread definition 352 of object340 to identify the particular thread definition that corresponds tothread 356.

Thread definitions (e.g., activities of an object) may includeindividual actions specific to the application functionality, which canbe executed in series, concurrently, or a combination thereof, withoutdependency on other threads. Thread definitions may be associated withobjects and may be interweaved with respect to time and sequence toprovide a process. Threads from thread definitions may execute more thanonce in a particular process and are not bound to execute in particularsequences. The quantity of distinct thread definitions of an object maydetermine a level of granularity of data that may be captured within theprocess specification.

The particular thread definition within the list of thread definitionsis identified, application class processing 320 may then execute process360 to obtain resource requirements 368 that indicate a list resourcetypes (e.g., record fields, attributes, processing cycles, processingtime, volatile memory, non-volatile memory, registers, networkbandwidth, or the like). For instance, some threads may execute on alocal processor using random access memory or cache memory. Otherthreads may require more substantial resource such as multi-coreprocessors, a network bandwidth, volatile and non-volatile memory, etc.Resource requirements 368 may indicate the resource types needed toexecute the application.

Application class processing 320 may then execute process 372 obtainingvalues for each resource type and generate a process specification forthread 356. The values of each resource type indicate the quantity ofresources consumed when thread 356 executed. In addition to the state ofthe process at the point in which thread 356 executed, processspecifications may include a trace of the process including the order inwhich each thread of the process executed before the process terminated.The trace may represent the threads a nodes within a tree structure withprocess 344 being the root node of the tree and each node thereafterbeing a thread that executed. In some instances, process keys mayassigned to each thread and to process 344. Process keys may indicatethe position within the tree that the corresponding thread is located.In other instances, the trace may represent the threads as a directedgraph where each node of the directed graph represents a thread. Arrowsfrom a node to another may represent a thread executing after anotherthread or a thread calling another thread. In still yet other instances,the trace may represent the threads as tables that include the resourcetypes, resource values, process keys, and the like for each thread ofprocess 344.

Once generated process specifications may be output 380 to local orremote persistent storage. In some instances, process specification maybe used to modify future processes or currently executing processes. Forinstance, a particular process for executing a resource request mayinclude threads that generate a resource request, transmit the resourcerequest to a first computing device within the distributed environment,transmit a new resource request to another computing device. As a resultof the first computing device lacking the appropriate resources,additional threads had to be executed. The process may be modified torequest a manifest of available resources from available computingdevices to reduce the threads of the process. The process may alsomodified by modifying the initial resource request to obtain availableresources from the first computing device and generate a second resourcerequest for the difference from another computing device.

Application layer 328 may execute the modified process in place of theprocess next time the process is initiated. In some instances, theprocess may be modified at runtime. Application layer 328 may detect thepoint in which the current thread is executing and modify a subsequentpointer to point to an address of the modified thread. Processors 376may reach the pointer and continue execution using the modified process.

FIG. 4 illustrates a block diagram of various processing views of avariant case during operation of semantic tagging according to at leastone aspect of the disclosure. FIG. 4 and FIG. 5 depict an exampleprocessing operation of a distributed application in which threadsexecute to request and obtain resources (e.g., articles, processorcycles or bandwidth, network bandwidth, memory, or the like). Forinstance, a three-dimensional modeling application require resource frommultiple computing devices in order to execute in real-time. Throughoutexecution the application may request resources such that small portionsof application may be executed by different computing devices. Theoutput may be transmitted to primary device which may then render thethree-dimensional model.

The application identify for each discrete process or thread, theresources necessary to execute the process or thread. In some instances,a portion of the resources may not be accessible to the process (e.g.,requested computing device lacks sufficient memory, processor bandwidth,etc.). If a particular computing device has the resources, the processor thread may be transferred for execution by the computing device and aresult of the execution (e.g., the articles, data, graphical userinterface, calculation, or the like) may be returned to the requester.

If no particular computing device has the available resources, theprocess may be sub-divided (e.g., based on threads, independent sets ofinstructions, or the like) into smaller processing units with a lowerresource requirement. Sub-dividing generate entirely newprocesses/threads or modify the existing process/thread to require lessresources (e.g., reducing instruction count, reducing memory usage suchas variables or registers, reducing loops such that a loop may executewith less iterations with the removed iterations executing withinanother process/thread, or the like) and generate one or more newprocesses/threads. The application may again initiate a request forresource to the multiple computing devices. In some instances, processmay be sub-divided down to individual instructions such that eachinstruction of the process may be executed by a different computingsystem.

In some instances, sub-dividing processes or threads may cause an errorwhen the new process or thread cannot be linked to the original processor thread. This may occur when the process or thread initiated prior tothe sub-dividing process. Process specifications, as represented in thesemantic tagging view, may provide the association between the rootprocess/thread and the new processes/threads. Maintaining the link tothe root process/thread may enable improving the root process asredundancy and cycles may be identified and eliminated.

Application process view may provide a representation of the processfrom the perspective of the application layer. Application layer mayinitiate a process 404 that executes a resource identification thread408 that identifies the resources by the application. Resourceidentification thread 408 may determine that the requested resourcescannot be acquired from any particular computing device. Resourceidentification thread 408 may call resource request thread 412, whichtransmits a resource request to a first computing device. The firstcomputing device may transmit an acknowledgement communication back toprocess 404. Resource allocation thread 416 may then transmit anallocation command to the first computing device to lock the resourcesto prevent another device or process form interfering. When theapplication no longer needs the resources a new thread may execute acommunication to release the locked resources.

Since the first computing devices cannot provide all of the requestedresources, a thread definition may be used to generate resource requestthread 420. Since resource request thread 420 was generated afterprocess 404 initialized, resource request thread 420 may not beassociated with process 404. Resource request thread 420, whichtransmits a resource request to a second computing device. The secondcomputing device may transmit an acknowledgement communication back toprocess 404. Resource allocation thread 424 may then transmit anallocation command to the second computing device to lock the resources.

The time line view represents the order in which each thread of process404 executes. Despite the resource request thread 420 being generated inparallel to the execution of resource request thread 412, the resourcerequest thread 412 and resource allocation thread 416 executed andterminated before resource request thread 420 and resource allocationthread 424 initiated.

The semantic tagging may provide a representation of the completeprocess reconstructed from one or more process specifications. Thesemantic tagging view includes additional data that links the addresource request thread 420 and resource allocation thread 424 to theprocess 404. In some instances, linking threads to a process may bebased on detecting a command from a thread calling another thread orrequesting a new thread be generated. In other instances, linkingthreads to a process may use indirect data such as a first thread beingassociated with a process and a second thread being associated with thefirst thread. Examples of criteria that may be used to link processes tothreads include, but is not limited to, proximity of execution ordersuch as when a first thread initiates execution within a threshold timeinterval of a second thread initiating execution, thread type such as aresource request, resource types, resource values, types of variables,previously executed thread, subsequently executed thread, combinationsthereof, and the like.

FIG. 5 is a block diagram of various processing views of a divergentcase during operation of semantic tagging according to at least oneaspect of the disclosure. The divergent case may occur when threadsdiverge, but each thread of the process can be traced back to theprocess initialization. For instance, process 504 initializes and callsidentify resources thread 508. In this case, the identify resourcesthread 508 generates two requests for resources, one to a firstcomputing device and a second to a second computing device. Identifyresources thread 508 calls resource request 512, which the callsresource allocation thread 516 to lock the resources of the firstcomputing device. Identify resources thread 508 also calls resourcerequest 520, which the calls resource allocation thread 524 to lock theresources of the first computing device.

The timeline view can represent the order in which the threads of thebranching process execute. Since the second resource request/allocationwas called with the first resource request/allocation, the resourcerequest 520 executed immediately after resource request 512. In someinstances, the execution order may be reversed with resource request 512executing after resource request 520. Resource allocation thread 524 mayexecute after resource allocation thread 516. In some instances,resource request 512 and resource allocation thread 516 may execute inparallel with resource request 520 and resource allocation thread 524.

The semantic tagging may provide a representation of the completeprocess reconstructed from one or more process specifications. Thesemantic tagging view includes additional data that indicates how theprocess 504 diverged into two parallel thread paths. For instance,process may execute a fork system call to generate the divergent threadpath. Rather than execute a single identify resources thread 508, asecond identify resources 528 may execute with each identify resourcethread executing to identify a smaller set of resources. Under thesemantic tagging view each thread can be traced back to the initiationof process 504 thereby providing a complete recreation of the state ofprocess 504 through the execution of each thread.

FIG. 6 is a flowchart of a process for generating process specificationsaccording to at least one aspect of the disclosure. At block 604, asemantic mapping API detects an execution of a particular thread by oneor more processors of a computing device. The semantic mapping API maybe an interface between an application class that instantiates processesand threads for execution and a configuration layer that indicates whattypes of processes/threads and data may be captured by the semanticmapping API. In some instances, each thread may include a thread keythat acts as a signature of the thread. Thread keys may be unique to theparticular thread and be generated by generating a hash (e.g., using acryptographic or checksum based hashing function) of the all or aportion of the instructions of the thread. The semantic mapping API mayincluding functions that may monitor a scheduler of the one or moreprocessors for the thread key. Threads may also include a processor keythat indicates the process within which the thread is executing.

In some instances, the thread keys may be generated based on theposition of the thread within the process similar to an address. Thethread key can be traced to identify other threads and processesassociated with the process by using the thread key. For instance,processes may be represented as a tree with the root process at the rootnode of the tree. The second layer of the tree may include threads (asrepresented by nodes) called by the root process initializationinstructions. The next layer may include threads (as represented bynodes) called from the threads of the previous layer and so on. Threadkeys may use a mime-type syntax that uses the calling thread's addressto generate the address for the called thread. For instance, given aroot process with the address P001, the second layer of threads may beaddressed as P001.01, P001.02 . . . P001.n. If the P001.01 thread calledtwo more threads, those threads may be represented as P001.01.01 andP001.01.02 and so on. The address of a particular thread of a processmay be used to trace the threads that executed prior to the particularthread.

At block 608, a root process of the particular thread may be identified.In some instances, the root node may be identified by tracing the threadkey of the particular thread. In other instances, the root process maybe identified by tracing memory addresses of the instructions executedby the processor. Tracing may span the entire cache memory,random-access memory, and persistent memory.

At block 612, a process-object link may be generated by linking anobject that called the particular thread and the process within whichthe thread executed. The object that called the particular thread may beidentified using the thread key, by a value of a field of the initiatingprocess, or by a value of a field of the particular thread. Objects mayinclude data, metadata, and instructions that execute to providefunctions of the application. For instance, for a resource requestprocess, an object may execute one or more threads for detectingresources of computing devices, requesting resources, allocatingresource, and the like. Objects may include a one or more threaddefinitions that can be instantiated to execute various functionsassociated with the object. The object's type may dictate the one ormore thread definitions included within the object such that differentobject types have different thread definitions. Each thread definitionmay be impendent and instantiated by the object into a thread, thethread being an instance of the thread definition. Each threaddefinition may include instructions to provide the functionality of thethread, resource types necessary to execute the thread, a value for eachresource type indicating a quantity of the resource type, an expectedinput, an output generated as a result of receiving the expected input,metadata, and the like.

At block 616, the process-object link may be used to identify a threadlist. The thread list includes the one or more thread definitions of theobject. One of the one or more thread definitions includes the threaddefinition that was instantiated to generate the instance of theparticular thread. The thread definition that correspond to theparticular thread may provide additional data that may indicate how thethread was expected to execute, the resources that were expected to beconsumed, and the like. The thread definition may indicate why aparticular branch was taken, why the thread induced a cycle or infiniteloop, and the like.

At block 620, A process specification may be generated for the processbased on the particular thread. The process specification may begenerated by: matching the particular thread definition thatcorresponded to the particular thread to the particular thread at block624.

At block 628, the particular thread definition may be used to identifyone or more resource types that may be necessary for the thread toexecute. The one or more resource types may include resources of thecomputing device, resources of other computing devices, resources of thenetwork, resources of other networks, combinations thereof, and thelike. Examples of resource types can include, but is not limited to,expected input types, attributes, processor cycles, processor bandwidth,cache memory, random-access memory, persistent memory, networkbandwidth, combinations thereof, and the like.

At block 632, a value corresponding to each resource type may bedefined. The value may correspond with a quantity of the resource thatmay be necessary to execute the particular thread, a quantity of theresource type that was actually consumed by the thread, or a combinationthereof. For instance, a thread may be executed to consume 100processing cycles. During a previous execution of the thread, 112processing cycles were consumed as a result of unanticipated instructionpath of the thread executing. The difference between the expected valueof the resource and the actual consumed value of the resource may beused to identify the cause the of extra resource consumption (e.g., theunanticipated instruction path) and modify the thread to reduce theresource consumption.

Resource consumption may be used to identify other inefficienciesincluding, but not limited to, improper memory allocations (e.g.,allocating too much or too little memory), inefficient looping (e.g.,loops that execute more than necessary to produce an expected output),recursion (e.g., when thread calls another instance of itself), invalidmemory typing, unused variables, and the like).

At block 636, the process specification may be generated. The processspecification may include some or all of: the thread definition, anidentification of the root process, the thread key, the process-objectlink, a memory dump of the entire process, list of threads, anidentification of the one or more resource types, an identification ofthe one or more values that correspond to the one or more resourcetypes, metadata, and the like. The process specification may be used toreproduce the state of the process at the point in which the particularthread executed. Multiple process specifications may correspond to asame process with each process specification representing the state ofthe process at a point of execution of different threads.

In some instances, a process may execute more than once (e.g., multipleexecutions of the same function within the application). Each time theprocess executes it may be associated with a different set of processspecifications. This may enable tracing each individual execution of theprocess. For instance, some processes may include errors such as memoryleeks may only be apparent during some executions of the process.Process specifications corresponding to each execution of the processmay be used isolate the root cause of the error by maintaining the stateof both processes in which the error occurred and processes in which theerror did not occur. Process specifications may be used for errordetection, root cause analysis, error correction, and increaseefficiency (e.g., reduce processing time or resources).

For instance, process specifications may be used to trace the rootprocess to identify the threads that executed before the particularthread (e.g., using the thread key) and the threads that executed after(using memory tracing or the like). The process specification maygenerate a directed graph in which each node of the graph represents athread that executed in the process based on the trace. Each node mayinclude a pointer to the node of the thread that executed after thenode. Other data structures may be used in addition to or in place of adirected graph such as tree, a table, a linked list, or the like. Thedirected graph may not be acyclic meaning one or more cycles may existin the graph. A cycle may represent a redundant thread path in which athread executed instead of point to a subsequent thread, pointed to apreviously executed thread causing the previously executed thread toexecute again. In some instances, a cycle may represent wasted resourcesin which some thread may execute more than necessary. In otherinstances, the cycle may represent an infinite loop in which theprocessor may stall executing the same set of threads over and overpreventing other functions from executing on the processor.

The direct graph may converted into a direct acyclic graph my removingthe cycle. Cycles may be removed by modifying the instructions of thethreads that are part of the cycle. For instance, the threads may bemodified to point to new threads rather than previously executedthreads, conditional branching may be removed, threads may be tested toidentify the cause of the redundancy (e.g., what input or processing iscausing the redundancy). This may lead to a modification of theinstructions or instruction order to eliminate the redundancy.

In some instances, threads that request or otherwise access resources ofother computing devices may be modified to request or otherwise accessthe resources of different computing devices. For instance, somecomputing devices may, at runtime, lack requested resources. A firstthread that requests those resources may stall or terminate as a result.The first thread may then call a previously executed thread to force theprocess to call the first thread again in an attempt to re-try theresource request. Since the computing lacks the requested resources,this loop may continue forever until the computing device has theavailable resources (if ever). Process specifications may be used tomodify the thread to request resources from a different computing deviceor from multiple different computing devices, which may therebyeliminate the cycle of the direct graph converting the graph to adirected acyclic graph.

A process may include a set number of threads that may increase ordecrease at runtime. For instance, given the resource request exampleabove, the first thread may request resources that cannot be satisfiedby the requested computing device. The first thread may be modified toreduce the amount of resources request and spawn a second thread torequest the difference. Since the first thread spawned the second threadrather than the process, the second thread may not be associated withthe same process. The process specification may be used to modify thesecond thread to link the second thread with the root process. Theresource request of the second thread may be associated with the processrequesting the resources, which may ensure the process is able toallocate the appropriate resources once the resource request threads(e.g., the first and the second) terminate.

In some instances, associating the second thread may necessitatesplitting the process specification into two process specifications thefirst process specification corresponding to the root thread, the firstthread, and each thread that was called from the first thread (e.g.,excluding the second thread, spawned as a parallel execution flow) andthe second process specification corresponding to the root thread, thefirst thread, and each thread that was called from the second thread.The first thread and the second thread may be identified using thethread key associated with each thread and a timestamp of the initiationof execution of each thread. Since the second thread spawned from thefirst thread, the timestamps can indicate the threads executed at closeto the same time interval. The thread keys may then indicate that thesecond thread spawned from the first thread.

Process specifications may be defined from other process specificationsas well as from executed threads. For instance, a root process or aparent thread may generate multiple threads that execute concurrently(e.g., synchronously or asynchronously) on one or more processors of oneor more computing devices (e.g., within a distributed environment). Aprocess specification of the parent process or thread may be used togenerate a process specification of each concurrently execution path. Afirst process specification may include (1) the root process or parentthread that initiated the concurrent execution flow by calling a firstthread, second thread . . . and nth thread, (2), the first thread, and(3) each thread that was called by the first thread and the threads thatwere called by those threads and so on until that concurrent executionpath terminates (e.g., there are no more threads). A second processspecification may include the root process or thread, the second thread,and each thread that was called by the second thread and the threadsthat were called by those threads and so on. A process specification maybe generated for each concurrent thread path to individually trace theparallel execution flow of the process.

Specific details are given in the above description to provide athorough understanding of the embodiments. However, it is understoodthat the embodiments may be practiced without these specific details.For example, circuits may be shown in block diagrams in order not toobscure the embodiments in unnecessary detail. In other instances,well-known circuits, processes, algorithms, structures, and techniquesmay be shown without unnecessary detail in order to avoid obscuring theembodiments.

Implementation of the techniques, blocks, steps and means describedabove may be done in various ways. For example, these techniques,blocks, steps and means may be implemented in hardware, software, or acombination thereof. For a hardware implementation, the processing unitsmay be implemented within one or more application specific integratedcircuits (ASICs), digital signal processors (DSPs), digital signalprocessing devices (DSPDs), programmable logic devices (PLDs), fieldprogrammable gate arrays (FPGAs), processors, controllers,micro-controllers, microprocessors, other electronic units designed toperform the functions described above, and/or a combination thereof.

Also, it is noted that the embodiments may be described as a processwhich is depicted as a flowchart, a flow diagram, a swim diagram, a dataflow diagram, a structure diagram, or a block diagram. Although adepiction may describe the operations as a sequential process, many ofthe operations can be performed in parallel or concurrently. Inaddition, the order of the operations may be re-arranged. A process isterminated when its operations are completed, but could have additionalsteps not included in the figure. A process may correspond to a method,a function, a procedure, a subroutine, a subprogram, etc. When a processcorresponds to a function, its termination corresponds to a return ofthe function to the calling function or the main function.

Furthermore, embodiments may be implemented by hardware, software,scripting languages, firmware, middleware, microcode, hardwaredescription languages, and/or any combination thereof. When implementedin software, firmware, middleware, scripting language, and/or microcode,the program code or code segments to perform the necessary tasks may bestored in a machine readable medium such as a storage medium. A codesegment or machine-executable instruction may represent a procedure, afunction, a subprogram, a program, a routine, a subroutine, a module, asoftware package, a script, a class, or any combination of instructions,data structures, and/or program statements. A code segment may becoupled to another code segment or a hardware circuit by passing and/orreceiving information, data, arguments, parameters, and/or memorycontents. Information, arguments, parameters, data, etc. may be passed,forwarded, or transmitted via any suitable means including memorysharing, message passing, token passing, network transmission, etc.

For a firmware and/or software implementation, the methodologies may beimplemented with modules (e.g., procedures, functions, and so on) thatperform the functions described herein. Any machine-readable mediumtangibly embodying instructions may be used in implementing themethodologies described herein. For example, software codes may bestored in a memory. Memory may be implemented within the processor orexternal to the processor. As used herein the term “memory” refers toany type of long term, short term, volatile, nonvolatile, or otherstorage medium and is not to be limited to any particular type of memoryor number of memories, or type of media upon which memory is stored.

Moreover, as disclosed herein, the term “storage medium” may representone or more memories for storing data, including read only memory (ROM),random access memory (RAM), magnetic RAM, core memory, magnetic diskstorage mediums, optical storage mediums, flash memory devices and/orother machine readable mediums for storing information. The term“machine-readable medium” includes, but is not limited to portable orfixed storage devices, optical storage devices, and/or various otherstorage mediums capable of storing that contain or carry instruction(s)and/or data.

While the principles of the disclosure have been described above inconnection with specific apparatuses and methods, it is to be clearlyunderstood that this description is made only by way of example and notas limitation on the scope of the disclosure.

What is claimed is:
 1. A method for modifying an application process,the method comprising: executing, at a first computing device, a firstthread of a plurality of threads of a first process of a plurality ofprocesses of an application, the first thread executing based on a callby an object; linking the object to the first process; identifying athread definition for the first thread, the thread definition definingresource requirements for execution of the first thread, the resourcerequirements including resource types and a value for each resourcetype, wherein the thread definition is identified by comparing the firstthread definition to a plurality of thread definitions of the object;generating the process specification for the first thread, the processspecification including the thread definition and the resourcerequirements, the process specification configured to reproduce a stateof the process at a time in which the first thread began executing, andmodifying, based on the process specification, a second process of theplurality of processes prior to the application spawning the secondprocess, wherein the second process is modified by using the processspecification to trace threads that were executed before the firstthread began executing.
 2. The method of claim 1, wherein linking theobject to the first process comprises: detecting, with a semanticmapping application programming interface, the execution of the firstthread; and identifying the first process by tracing a thread key of thefirst thread.
 3. The method of claim 1, wherein identifying the threaddefinition for the first thread comprises: identifying a thread listthat includes a plurality of thread definitions of the object, theplurality of thread definitions of the object; and matching a threaddefinition included in the plurality of thread definitions of the objectto the thread definition for the first thread.
 4. The method of claim 1,wherein the resource types comprise processor cycles of a computingdevice.
 5. The method of claim 4, wherein the value of each resourcetype comprises a number of the processor cycles of the computing device.6. The method of claim 1, further comprising: executing, at the firstcomputing device, a second thread of the plurality of threads of thefirst process of the plurality of processes of the application, thesecond thread executing based on the call by the object, wherein thesecond thread is a resource identification thread identifies resourcesneeded to execute the application: determining, based on the resourceidentification thread, that the first computing device has insufficientresources to execute the application; calling a first resource requestthread, the first resource request thread transmitting a first resourcerequest to the first computing device; calling a first resourceallocation thread, the first resource allocation thread transmitting afirst allocation command to the first computing device, the firstallocation command instructing the first computing device to lockavailable resources of the first computing device; calling a secondresource request thread, the second resource request thread transmittinga resource request to a second computing device; calling a secondresource allocation thread, the second resource allocation threadtransmitting a second allocation command to the second computing device,the second allocation command instructing the second computing device tolock available resources of the second computing device; and providing arepresentation of the first process of the application based on at leastone process specification, the representation of the process linking thesecond resource request thread and the second resource allocation threadto the first process of the application, wherein the at least oneprocess specification indicates a state of the first process of theapplication when the first process is initiated.
 7. A system,comprising: one or more computing devices; and one or morecomputer-readable storage media containing instructions which, whenexecuted by the one or more computing devices, cause the one or morecomputing devices to perform operations including: executing, at a firstcomputing device of the one or more computing devices, a first thread ofa plurality of threads of a first process of a plurality of processes ofan application, the first thread executing based on a call by an object;linking the object to the first process; identifying a thread definitionfor the first thread, the thread definition defining resourcerequirements for execution of the first thread, the resourcerequirements including resource types and a value for each resourcetype, wherein the thread definition is identified by comparing the firstthread definition to a plurality of thread definitions of the object;generating the process specification for the first thread, the processspecification including the thread definition and the resourcerequirements, the process specification configured to reproduce a stateof the process at a time in which the first thread began executing, andmodifying, based on the process specification, a second process of theplurality of processes prior to the application spawning the secondprocess, wherein the second process is modified by using the processspecification to trace threads that were executed before the firstthread began executing.
 8. The system of claim 7, wherein linking theobject to the first process comprises: detecting, with a semanticmapping application programming interface, the execution of the firstthread; and identifying the first process by tracing a thread key of thefirst thread.
 9. The system of claim 7, wherein identifying the threaddefinition for the first thread comprises: identifying a thread listthat includes a plurality of thread definitions of the object, theplurality of thread definitions of the object; and matching a threaddefinition included in the plurality of thread definitions of the objectto the thread definition for the first thread.
 10. The system of claim7, wherein the resource types comprise processor cycles of a computingdevice.
 11. The system of claim 7, wherein the value of each resourcetype comprises a number of the processor cycles of the computing device.12. The system of claim 7, the operations further comprising: executing,at the first computing device, a second thread of the plurality ofthreads of the first process of the plurality of processes of theapplication, the second thread executing based on the call by theobject, wherein the second thread is a resource identification threadidentifies resources needed to execute the application: determining,based on the resource identification thread, that the first computingdevice has insufficient resources to execute the application; calling afirst resource request thread, the first resource request threadtransmitting a first resource request to the first computing device;calling a first resource allocation thread, the first resourceallocation thread transmitting a first allocation command to the firstcomputing device, the first allocation command instructing the firstcomputing device to lock available resources of the first computingdevice; calling a second resource request thread, the second resourcerequest thread transmitting a resource request to a second computingdevice of the one or more computing devices; calling a second resourceallocation thread, the second resource allocation thread transmitting asecond allocation command to the second computing device, the secondallocation command instructing the second computing device to lockavailable resources of the second computing device; and providing arepresentation of the first process of the application based on at leastone process specification, the representation of the process linking thesecond resource request thread and the second resource allocation threadto the first process of the application, wherein the at least oneprocess specification indicates a state of the first process of theapplication when the first process is initiated.
 13. A non-transitorycomputer-readable medium storing instructions that when executed by oneor more computing devices cause the one or more computing devices toperform operations including: executing, at a first computing device ofthe one or more computing devices, a first thread of a plurality ofthreads of a first process of a plurality of processes of anapplication, the first thread executing based on a call by an object;linking the object to the first process; identifying a thread definitionfor the first thread, the thread definition defining resourcerequirements for execution of the first thread, the resourcerequirements including resource types and a value for each resourcetype, wherein the thread definition is identified by comparing the firstthread definition to a plurality of thread definitions of the object;generating the process specification for the first thread, the processspecification including the thread definition and the resourcerequirements, the process specification configured to reproduce a stateof the process at a time in which the first thread began executing, andmodifying, based on the process specification, a second process of theplurality of processes prior to the application spawning the secondprocess, wherein the second process is modified by using the processspecification to trace threads that were executed before the firstthread began executing.
 14. The non-transitory computer-readable mediumof claim 13, wherein linking the object to the first process comprises:detecting, with a semantic mapping application programming interface,the execution of the first thread; and identifying the first process bytracing a thread key of the first thread.
 15. The non-transitorycomputer-readable medium of claim 13, wherein identifying the threaddefinition for the first thread comprises: identifying a thread listthat includes a plurality of thread definitions of the object, theplurality of thread definitions of the object; and matching a threaddefinition included in the plurality of thread definitions of the objectto the thread definition for the first thread.
 16. The non-transitorycomputer-readable medium of claim 13, wherein the resource typescomprise processor cycles of a computing device.
 17. The non-transitorycomputer-readable medium of claim 13, wherein the value of each resourcetype comprises a number of the processor cycles of the computing device.18. The non-transitory computer-readable medium of claim 13, theoperations further comprising: executing, at the first computing device,a second thread of the plurality of threads of the first process of theplurality of processes of the application, the second thread executingbased on the call by the object, wherein the second thread is a resourceidentification thread identifies resources needed to execute theapplication: determining, based on the resource identification thread,that the first computing device has insufficient resources to executethe application; calling a first resource request thread, the firstresource request thread transmitting a first resource request to thefirst computing device; calling a first resource allocation thread, thefirst resource allocation thread transmitting a first allocation commandto the first computing device, the first allocation command instructingthe first computing device to lock available resources of the firstcomputing device; calling a second resource request thread, the secondresource request thread transmitting a resource request to a secondcomputing device of the one or more computing devices; calling a secondresource allocation thread, the second resource allocation threadtransmitting a second allocation command to the second computing device,the second allocation command instructing the second computing device tolock available resources of the second computing device; and providing arepresentation of the first process of the application based on at leastone process specification, the representation of the process linking thesecond resource request thread and the second resource allocation threadto the first process of the application, wherein the at least oneprocess specification indicates a state of the first process of theapplication when the first process is initiated.